home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 655 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.2 KB
  1. From: Torsten Scherer <itschere@techfak.uni-bielefeld.de>
  2. Subject: XATTR structure for BIOS filesystem #2
  3. Date: Sun, 21 Nov 93 13:37:40 +0100
  4.  
  5. Hi people!
  6.  
  7.   During my "research" for implementing a complete XATTR structure for
  8. entries in the BIOS filesystem (see mail some days ago), I've now - after
  9. having some discussion about security problems and so - strumbled about the
  10. datime() function each device driver has got to provide and I wonder if this
  11. one could be used to report the time/datestamps needed.
  12.  
  13.   So far, it does not support all m/a-time/date fields, but I think this
  14. could perhaps be easily fixed by the following idea:
  15.  
  16.   Most device drivers just seem to test if the rwflag is non-zero to check
  17. if a write call is wanted, although my documentation (german Profibuch) says
  18. explicitly a write call has to set rwflag=1. If one could rely on this fact,
  19. it would be easy to implement modes 2-3 to report the m/a-t/d fields (c-t/d
  20. is unlikely to change :-), if not, you'd have to face the fact that the
  21. device driver would interpret this as a write call.
  22.  
  23.  This may not be too much disturbing, since this call would be used only for 
  24. internal kernel use and would only be done for biosfs entries. So if you use
  25. a new-style driver everything's fine, and if your driver doesn't understand
  26. this it either reports an error - in which case you still can use the current
  27. time just like the biosfs does up to now - or it would set its values to the
  28. ones given, which mightn't do any harm if the caller preset's them with the
  29. current time fields. The device would than act exactly like if it was running
  30. on an older kernel which doesn't know about all these.
  31.  
  32.   This would only involve changes in the biosfs.c code and would _not_ offer
  33. the driver the possibility to manipulate its own XATTR structure in order to
  34. do strange things like gaining superuper priority.
  35.  
  36.   Does this sound like a good idea? It _seems_ to run ok on my setup.
  37.  
  38. so long,
  39. TeSche
  40. ---
  41. PS: If the above written looks weird, then that's probably because it _is_.
  42. WhoDunnIt: Torsten Scherer (Schiller, Tesche, ...)
  43. Where: Faculty of Technology, University of Bielefeld, Germany
  44. EMail: itschere@techfak.uni-bielefeld.de / tesche@hrz.uni-bielefeld.de
  45.